NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/2301

Internet Message Format | 1996-08-05 | 6.9 KB

Path: comma.rhein.de!serpens!not-for-mail
From: [e-mail] (Michael van Elst)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Demo/game to OS friendly part II
Date: 30 Jan 1996 00:57:00 +0100
Organization: dis-
Message-ID: <4ejmsc$[e-mail]>
References: <4e0jhq$[e-mail]> <4e114i$[e-mail]> <4e371l$[e-mail]> <4e3jld$[e-mail]> <4e5k20$[e-mail]> <4e64u7$[e-mail]> <4e9n67$[e-mail]> <4eb61a$[e-mail]> <4ej5du$[e-mail]>
NNTP-Posting-Host: serpens.rhein.de

[e-mail] (Juergen "Rally" Fischer) writes:

>|> Native = planar & chipmem. Doesn't mean that you have a blitter or
>|> even a compatible blitter. Of course up to now this _assumption_

>well, how could I know, that the OS writers have different oppinion
>about the term "chipmem".

You shouldn't try to guess. You should accept information and follow it.

The information says that native bitmaps have a certain layout and
may be used by the blitter. It does not say that this implies the existence
of a blitter.

The information also says that you can query this hardware in GfxBase.

>so "chipmem" means here "mem where planar bitmap can be made visible" ?

no. because planar bitmaps could exist anywhere. but these wouldn't
be "native".

>so, could a driver tell a bitmap is "native", with bitmap located in
>fastmem (and OS-functions doing the rest) ?

Difficult. It would have to rely on the fact that nobody could try to
use the blitter on it.

>So I would say, "native" is planar & in the mem the OS-calls get the
>data into screens/windows. No chipmem at all!

Read above. A native bitmap has standard format, is planar and it
might be accessed by the blitter.

>then, how to check if my native bitmap is blitterable by AGA or
>compatible blitter ?

You don't have to. It is.

>I guess all the people who asked for the
>"native" check will assume the mem is blitterable by $dff058.

$dff058 is whatever...

Anyway. All that people that assume that a native bitmap can be
handled by the blitter are correct. That's the definition.

However, to verify that you actually have a blitter (and what blitter
you have) you must query GfxBase.

>shock, what about allocmem(chip) ?

shock ?

>but you say using the 3 pass version is wrong under any condition ?

No, I haven't said this either.

>Writepixellarray8 can only get as fast as my hack if

>a) OS introduces interleaved planar viewports for AGA and previous chips.

You probably think of something completely different. But yes, the OS does
support interleaved planar viewports.

>b) let's me select how much passes are done by cpu or blitter (for each
>   writeparr8() call).

What for ?

>c) the updated area got same width like screen

Well, if the updated area is smaller it could probably be faster than
your hack. And that's not "as fast as" your hack. So you are right.

>I admit it won't work well for 640er res, no 1280res,
>only 320res on dblmonitors and then chipmem bus gets
>into traffic jam. So the new modus is to be opened only
>when running PAL LORES (mhm, where to I know this
>specifiaction from ;) hihi ;)

The actual c2p operation has probably nothing to do with the display mode.

>so what are we wrestling about ? :D you somehow don't like direct
>render, did I read this right ?

Direct rendering has some disadvantages.

>|> >you told me
>|> >not to use hi-pri waittof therefore.
>|>
>|> No, I didn't.

>Maybe you did think something different writing a sentence that
>would be interpreted by most people (I said people, not c0d3r)
>like I did. well.

Does your brain hurt when you write such funny things ?

>maybe. So what you tell, what you flame ?

Programming style of c00l c0d3rz like you. Isn't that obvious ? Even you
should have noticed that.

>|> It should get you a display where you can poke the bitmap. And sorry,
>|> this wouldn't work everywhere.

>It would. You don't know the routine as I didn't write RKMs for it ;)

Why do you argue facts ? There are displays that do not _have_ a bitmap
for you to poke.

>It just canceles direct render mode when not available on that
>platform (Your A3000, SGI, etc.). But it will return a array you got
>to render to, so no failing.

So you forgot an extra update function that copies that array to the
screen. Something like WritePixelArray8.

>there was a way to do the required thing. OS routines are to
>do hardwarepokes.

Sure they are so that YOU do not have to.

>programmer ? you mean the caller of my routine now ? He got to render
>to the given array, and then call the updateroutines, that's all.

Of course I do _not_ mean the caller of your routine. I mean _you_.

>Maybe you'd need to specify more than a bool value to tell how
>realtimish your effect is to give the interface a chance for right
>decision.

Or simply ignore the fine details as you cannot control them ?

>Why not. programmer can test if they're faster than his tricks
>(they're maybe slower if no hardware present, see writeparr8(). )

If you do not use the OS interface you have to support every hardware.
And as a matter of fact: you don't.

>Then I display the buffer, i.e video-buffer shows the line next
>frame without any copying.

Of course the buffer might be displayed at the same time. You don't know.

>This is what I don't like. It's avoidable.

Sure. Like busywaiting with WaitTOF() or refetching ExecBase for each function.

>used Amiga. If I also provide a OS version, you can't
>flame me for anything.

You first have to provide an OS version. And regarding your questions about
OS programming I say that you have a tough time.

>|> Sure it does.

>Why always this short replys. You want to tell the "even vanilla A1200
>aren't 100% compatible" story ? well, the PAL ones are a bit slower ;)

Of course even vanilla A1200s are not compatible. Look at the recent
trackloader disaster.

But no. Code can be junk even if it happens to work.

>Imagine a code that works right on OS3.0, works right just
>because the done assumtions (copjmp2 not needed in syscoplist)
>are true for OS3.0. If the A1200+ still got AGA, and if the
>code doesn't contain any other assumtions, the only way
>to make it crash is having a different OS, which uses copjmp2
>for some purpose. Is it clear now ?

It has been clear from the beginning. You do invalid assumptions and as
a result your code crashes.

>The irony is that if the new OS needs copjmp2, there is no chance for
>my "ucopl copjmp2 slight hack without acessing $dffxxx", but a copper
>takeover routine still got a chance. quite weird!

Not weird at all. You are not supposed to use hacks because hacks do fail.
That's a simple truth.

>And happy gamerz are the aim, not happy philosophes.

Happy gamers buy PCs or PlayStations.

--
                                Michael van Elst

Internet: [e-mail]
                                "A potential Snark may lurk in every tree."